Method of verifying key validity and server for performing the same

ABSTRACT

Disclosed herein is a method of verifying key validity and a server for performing the method. The method is configured such that a service provision server verifies key validity in an anonymous service for providing local linkability. The service provision server receives a revocation list. A local revocation list is generated using the received revocation list and a secret key. A virtual index of a service user required to verify key validity is calculated. Whether a key of the service user is valid is verified, based on whether the virtual index is included in the local revocation list.

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of Korean Patent Application No. 10-2010-0131001, filed on Dec. 20, 2010, which is hereby incorporated by reference in its entirety into this application.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to a method of verifying key validity and a server for performing the method. More particularly, the present invention relates to a method of verifying the validity of keys in anonymous authentication that provides local linkability and to a server for performing the method.

2. Description of the Related Art

Recently, as the privacy of each individual person has become important, schemes for authenticating a user based on anonymity instead of authentication based on the real name of the user have been developed. That is, most services do not need to check the real name of a specific person, and for these services, simply checking whether the user has authority to access a relevant service (for example, whether the user is an adult) may be sufficient in many cases.

A representative method of checking whether the user has authority to access a service is the short group signature scheme that was investigated and published by D. Boneh et al.

Such a short group signature scheme includes basic functions for conditionally traceable anonymity such as anonymity, traceability, and unlinkability.

However, when unlinkability is applied to typical Internet services, a great increase in inconvenience may result. When a user is provided with the same service while being continuously authenticated, a service provider cannot recognize whether the user is the same service user, and thus it is impossible to provide a member management service and various types of services based on such member management (for example, a mileage service).

Since linkability enables the course of a person to be traced, its introduction is characterized by being undesirable from the viewpoint of privacy.

A conventional anonymous authentication method is configured to provide linkability only in a specific service domain, and provide local linkability between different service domains so that linking is not supported in relation to whether users are the same service user, thus making it impossible to trace the course of each service user while enabling members to be managed anonymously.

In such an anonymous authentication method, it can be determined whether a service user possesses a correct key by verifying a signature that is furnished by the service user, but it is very inefficient to determine whether the key has been revoked or the key is no longer valid.

A Public Key Infrastructure (PKI) based on X.509 provides a Certificate Revocation List (CRL), an Online Certificate Status Protocol (OCSP), etc. In the PKI, since each certificate includes a unique number, the unique number is compared to the certificate revocation list, thus enabling the validity of a key to be easily verified.

However, those anonymous authentication methods issue unique keys to respective service users, but those keys are not directly exposed when a signature is created and when verification is performed, so that it is impossible to compare key values. As a result, other inefficient schemes must be inevitably used.

Methods of verifying key validity in anonymous authentication methods are classified into an online key update method and a Verifier Local Revocation (VLR) method.

Such an online key update method is a method of updating public keys and the secret keys (or private keys) of all service users using revoked keys. The online key update method prohibits the user of a revoked key from updating a secret key, thus naturally preventing the user of the revoked key from creating his or her signature.

Such a VLR method is a method in which a signature verifier or a service provider directly performs verification, and which determines whether a key has been revoked upon verifying a signature using a published revocation list.

All of the above anonymous authentication methods have the following problems related to inefficiency.

The online key update method is problematic in that when the length of a revocation list increases, it may take a long time for a service user to update his or her secret key before creating a signature.

For example, such an online key update method is disadvantageous in that unless a service user always makes online access, if the service user makes online access after a long period of time has passed by in the case where the service user irregularly makes online access and updates a secret key, the update of the secret key must be performed using a significantly long revocation list. This may not fulfill the requirements of a service user who desires to be anonymously authenticated immediately or within several seconds.

Such a VLR method is characterized in that since a service provider always makes online access, a revocation list can be continuously received, but is problematic in that the time required to verify a signature is lengthened in proportion to the length of the revocation list.

That is, when a signature is verified, computations corresponding to the computation level of a public key are required in an algorithm for verifying validity. In this case, there is a problem in that when the length of a revocation list increases, the time required by the service provider is proportional to the length of the revocation list, and thus long computations must be performed whenever a signature is verified.

SUMMARY OF THE INVENTION

Accordingly, the present invention has been made keeping in mind the above problems occurring in the prior art, and an object of the present invention is to provide a method of verifying key validity in anonymous authentication that provides local linkability, and a server for performing the method.

In accordance with an aspect of the present invention to accomplish the above object, there is provided a method of verifying key validity, the method being configured such that a service provision server verifies key validity in an anonymous service for providing local linkability, including receiving a revocation list at the service provision server; generating a local revocation list using the received revocation list and a secret key; calculating a virtual index(=local anonymous identifier) of a service user required to verify validity of a key of the service user; and verifying whether a key of the service user is valid, based on whether the virtual index is included in the local revocation list.

Preferably, the receiving the revocation list may be configured such that the service provision server receives the revocation list that corresponds to a set of keys of users, generated when an anonymous authentication server revokes anonymous secret keys, and that has been published by the anonymous authentication server.

Preferably, the verifying whether the key of the service user is valid may include determining that authentication has been requested using a valid key that has not been revoked if the virtual index is not included in the local revocation list.

Preferably, the verifying whether the key of the service user is valid may include determining that authentication has been requested using an invalid key that has been revoked if the virtual index is included in the local revocation list.

In accordance with another aspect of the present invention to accomplish the above object, there is provided a service provision server for verifying key validity in an anonymous service for providing local linkability, including a list generation module for generating a local revocation list using a revocation list and a secret key; an index generation module for, generating a virtual index of a service user; and a verification module for verifying whether a key of the service user is valid, based on whether the virtual index is included in the local revocation list.

Preferably, the revocation list may be a list that corresponds to a set of keys of users, generated when an anonymous authentication server revokes anonymous secret keys, and that has been published by the anonymous authentication server.

Preferably, the verification module may be configured either to determine that authentication has been requested using a valid key that has not been revoked if the virtual index is not included in the local revocation list or to determine that authentication has been requested using an invalid key that has been revoked if the virtual index is included in the local revocation list.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features and advantages of the present invention will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a diagram showing an anonymous service system using a typical short group signature;

FIG. 2 is a diagram showing an anonymous service method for providing local linkability;

FIG. 3 is a flowchart showing the initialization procedure of FIG. 2 in detail;

FIG. 4 is a flowchart showing the service user join step of FIG. 3 in detail;

FIG. 5 is a flowchart showing the service provider join step of FIG. 4 in detail;

FIG. 6 is a flowchart showing the group signature creation procedure of FIG. 4 in detail;

FIG. 7 is a flowchart showing the local link procedure of FIG. 4 in detail;

FIG. 8 is a flowchart showing a method of verifying key validity according to an embodiment of the present invention;

FIG. 9 is a block diagram showing a server for performing the key validity verification method according to an embodiment of the present invention, and

FIG. 10 is a diagram illustrating an example of the verification of key validity according to an embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Reference now should be made to the drawings, in which the same reference numerals are used throughout the different drawings to designate the same or similar components.

The present invention will be described in detail below with reference to the accompanying drawings. In the following description, redundant descriptions and detailed descriptions of known functions and elements that may unnecessarily make the gist of the present invention obscure will be omitted. Embodiments of the present invention are provided to fully describe the present invention to those having ordinary knowledge in the art to which the present invention pertains. Accordingly, in the drawings, the shapes and sizes of elements may be exaggerated for the sake of clearer description.

Hereinafter, a method of verifying key validity and a server for performing the method according to embodiments of the present invention will be described in detail with reference to the attached drawings.

Prior to describing the method of verifying key validity according to the present invention, a short group signature scheme which is the basis of the present invention will be primarily described.

A group signature scheme was initially proposed by D. Chaum et al. in EUROCRYPT conference in 1991, and is configured such that any member belonging to a group can create a signature and a verifier can verify whether the signature is correct or incorrect, but cannot know any information about a signer. A group manager is the most important entity in the group signature scheme, and is capable of finding out the identity of a group signer by tracing the group signature.

A short group signature scheme is a kind of group signature scheme proposed by D. Boneh et al. in the CRYPTO conference in 2004, and is advantageous in that the length of a signature is fixed and is short (1533 bits) and the time required for a signature and verification is relatively short.

FIG. 1 is a diagram showing an anonymous service system using a typical short group signature.

Referring to FIG. 1, the anonymous service system may include a service terminal 100, an anonymous authentication server 110, a service provision server 120, and an anonymous identification (ID) verification server 130.

The service terminal 100 is a device configured to allow a user to be issued with an anonymous authentication means (anonymous ID∥secret key) from the anonymous authentication server 110 and to anonymously use the service. Since the service terminal 100 according to the embodiment of the present invention is driven and used by the service user, the service terminal will be collectively called the service user for the sake of description.

The anonymous authentication server 110 verifies the real name of the service user and issues an anonymous authentication means to the service user. If there is a problem, the anonymous authentication server 110 can trace the real name of the user in conjunction with the anonymous ID verification server 130, but it cannot independently perform tracing.

The service provision server 120 anonymously provides the service, and can request the anonymous ID verification server 130 to trace the real name of an anonymous user if there is a problem.

The anonymous ID verification server 130 can receive an anonymous authentication transaction from the service provision server 120 and verify the anonymous ID from the anonymous authentication transaction.

An existing group signature such as a short group signature has the characteristics of making it difficult to provide unlinkability. That is, for two signatures, none but the anonymous ID verification server can determine whether those signatures have been generated by the same service user. These characteristics have the disadvantage of making it difficult to introduce the anonymous authentication scheme to a member-based service.

For linkability, a fictitious name-based scheme can be utilized, but this scheme enables the course of a specific service user to be traced because all of authentication means generated from one fictitious name are linked. In addition, since such a fictitious name-based scheme also enables the real name of the user to be derived using a social method, it is not regarded as a good scheme.

In order to supplement for these insufficiencies, an anonymous authentication scheme for providing local linkability has recently been introduced. The term ‘local linkability’ denotes the state in which it is possible to determine whether individual anonymous authentication transactions are those of the same user in a specific service domain, so that members can be managed in that domain, whereas it is impossible to determine whether anonymous authentication transactions between different service domains are those of the same user.

FIG. 2 is a flowchart showing an anonymous authentication method of providing local linkability.

As shown in FIG. 2, the anonymous authentication method includes an initialization (setup) procedure (step S200), a join procedure (step S210), a group signature creation (sign) procedure (step S220), a group signature verification procedure (step S230), a signer identification (open) procedure (step S240) and a local link procedure (step S250).

The individual procedures of the method will be described in detail below.

First, in the setup procedure (S200), the anonymous authentication server 110 performs the following procedure, as shown in FIG. 3.

At step S201, the anonymous authentication server 110 receives a security parameter K as input and performs a subsequent procedure. First, the anonymous authentication server 110 generates a computable isomorphic function φ combined with a bilinear group pair “(G₁, G₂)”, a bilinear function (e: G₁×G₂→G_(T)), and a hash function (H: {0, 1}*→Z_(p)) using group public parameters (e, G₁, and G₂). Further, any generation sources (g₂εG₂\{1_(G) ₂ } and g₀, g₃, g₄, hε\{1_(G) ₁ }) are selected, g₁=φ(g₂) is calculated, a master secret key (or private key) (γεZ*_(p)) is selected, and a group public key element (w=g₂ ^(γ)εG₂) is calculated, so that an initial group public key (gpk=(g₀, g₁, g₂, g₃, g₄, w)) is obtained.

At step S202, the anonymous authentication server 110 publishes the group public key to all participants. In this case, the group public key is updated whenever a revocation event occurs. Further, “η₁←e(g₁, g₂), η₄←e(g₃, g₂), and η₅←e(g₄, g₂)” required to reduce the computation of a pairing function of the group public key can be selectively included in the public key.

Thereafter, in the join procedure at step S210, a service user join step S211 and a service provider join step S212 are performed, as shown in FIG. 2. In this case, the service user join step S211 is a procedure for the service user 100 who desires to join the group and use a group signature key, and the service provider join step S212 is a procedure for the service provision server for ensuring local linkability.

The service provider join step is generally performed before the anonymous service is provided, and if possible, a service provider must avoid being reissued with a key after having been initially issued with a key so as to maintain the continuity of the service. The service user can undergo the service user join step anytime, and it must be possible for a single service user to be issued with a group signature secret key several times while undergoing the service user join step.

As shown in FIG. 4, it is assumed that the service user join step S211 is performed by both the service user 100 and the anonymous authentication server 110, and, in this regard, a security channel is established between the service user 100 and the anonymous authentication server 110.

At step S211-1, the service user 100 selects its own secret key (y_(i)εZ*_(p)) and calculates a public key (g₃εG₁). Further, A proof of possession (POP) of the secret key (y_(i)), that is, information (POP(y_(i))) proving that the secret key (y_(i)) has been possessed, is generated using the public key (g₃). Thereafter, the service user 100 transmits “identification information and POP(y_(i))” to the anonymous authentication server 110. This information (POP(y_(i))) must include g₃ ^(−y) ^(i) or information used to directly calculate this value.

At step S211-2, the anonymous authentication server 110 receives “identification information and POP(y_(i))” transmitted from the service user 100 who desires to join, verifies the validity of the received information, and then determines whether the service user 100 has rejoined using the following procedure. First, a list of service users has a format such as “(identification information, POP(y_(i)), z_(i) and g₀ ^(−z) ^(i) )”, where z_(i) and g₀ ^(−z) ^(i) always have fixed values for a single service user.

At step S211-3, if the service user 100 has already joined and relevant identification information is present in a list of users (User-List), the anonymous authentication server 110 obtains z_(i) registered with respect to the relevant user in the user list, selects any random number x₁εZ*_(p), and calculates an anonymous ID, that is, A_(i)=(g₁g₄ ^(−z) ^(i) g₃ ^(−y) ^(i) )^(1/(γ+x) ^(i) )εG₁. Further, the anonymous authentication server 110 transmits (A_(i), x_(i), z_(i)), which is generated as the group member key of the service user 100, to the relevant service user 100.

At step S211-4, if the service user 100 initially joins and so the “(identification information and POP(y_(i)))” of the user are not registered in the user list, the anonymous authentication server 110 selects any random numbers x_(i), z_(i)εZ*_(p), and calculates an anonymous ID A_(i)=(g₁g₄g₃ ^(−y) ^(i) )^(1/(γ+x) ^(i) )εG₁. Further, the anonymous authentication server 110 registers the relevant service user 100 by adding the “(identification information, POP(y_(i)), z_(i), g₀ ^(−z) ^(i) )” to the user list while transmitting the group member key (A_(i), x_(i), z_(i)) of the service user 100 to the service user 100 (wherein g₀ ^(−z) ^(i) corresponds to an anonymous ID fixed to the specific user, and will simply be abbreviated as ‘B_(i)’ hereinafter).

At step S211-5, the service user 100 receives the group member key (A_(i), x_(i), z_(i)), and thereafter determines whether the following Equation 1 is valid. If it is determined that the following Equation 1 is valid, the service user 100 stores gsk[i]=(A_(i), x_(i), z_(i), y_(i)) as his or her own group signature secret key.

e(A _(i) ,w·g ₂ ^(x) ^(i) )=e(g ₁ g ₄ ^(−z) ^(i) g ₃ ^(−y) ^(i) ,g ₂)(=η₁·η₅ ^(−z) ^(i) ·η₄ ^(−y) ^(i) )  (1)

e( ): cryptographic bilinear pairing map A_(i), x_(i), z_(i), y_(i) group member key g₁, g₂, g₃, g₄, w: group public key

As shown in FIG. 5, the service provider join step S212 is performed by both the service provision server 120 and the anonymous ID verification server 130. Here, it is assumed that a security channel is established between the service provision server 120 and the anonymous ID verification server 130.

At step S212-1, the service provision server 120 transmits its own SP identification information to the anonymous ID verification server 130.

At step S212-2, the anonymous ID verification server 130 receives the SP identification information from the service provision server 120, verifies the validity of the SP identification information, selects any generation sources “m_(i)εG₁\{1_(G) ₁ } and m_(j)εG₂\{1_(G) ₁ }” and random numbers “χ_(j), ξ_(1j), ξ_(2j)εZ*_(p)”, and calculates h_(j)=m_(j) ^(χ) ^(j) , u_(j)=m_(j) ^(ξ) ^(1j) ⁻¹ , v_(j)=m_(j) ^(ξ) ^(2j) ⁻¹ εG₁, U_(j)=M_(j) ^(ξ) ^(1j) and V_(j)=M_(j) ^(ξ) ^(2j) εG₂ Further, after calculating a pair of public keys and secret keys for a local link (h_(j), m_(j), u_(j), v_(j), M_(j), U_(j), V_(j)) and a trace key(tk_(SP)[j]=(χ_(j), ξ_(1j), ξ_(2j))), the anonymous ID verification server 130 transmits the pair of public keys and secret keys (h_(j), m_(j), u_(j), v_(j), M_(j), U_(j), V_(j)) to the service provision server 120.

The Local Link (LL) public key of the service provision server 120 can be represented by “LLpk_(SP)[j]=(h_(j), m_(j), u_(j), v_(j)) (where h_(j)=m_(j) ^(χ) ^(j) , u_(j)=m_(j) ^(ξ) ^(1j) ⁻¹ , v_(j)=m_(j) ^(ξ) ^(2j) ⁻¹ εG₁, m_(j)εG₁\{1_(G) ₁ }, and χ_(j), ξ_(1j), ξ_(2j)εZ*_(p))”, the LL secret key can be presented by “LLsk_(SP)[j]=(M_(j), U_(j), V_(j)) (where M_(j)εG₂\{1_(G) ₁ }, U_(j)=M_(j) ^(ξ) ^(1j) , V_(j)=M_(j) ^(ξ) ^(2j) εG₂)”, and the trace keycan be represented by “tk_(SP)[j]=(ξ_(1j), ξ_(2j), χ_(j)) (where χ_(j), ξ_(1j), ξ_(2j)εZ*_(p))”.

At step S212-2, the anonymous ID verification server 130 registers the service provision server 120 by adding ((h_(j), m_(j), u_(j), v_(j), M_(j), U_(j), V_(j)), SP identification information, and (χ_(j), ξ_(1j), ξ_(2j))) to a service provision server list (SP-List).

At step S212-3, the service provision server 120 receives the pair of public keys and secret keys (h_(j), m_(j), u_(j), v_(j), M_(j), U_(j), V_(j)), and then determines whether the following Equation 2 is valid. If it is determined that the following Equation 2 is valid, the service provision server 120 stores “LLsk_(SP)[j]=(M_(j), U_(j), V_(j))” as its own LL secret key, and generates and publishes the LL public key (LLpk_(SP)[j]=(h_(j), m_(j) u_(j), v_(j))).

e(m _(j) ,M _(j))=e(u _(j) ,U _(j))=e(v _(j) ,V _(j))  (2)

e( ): cryptographic bilinear pairing map m_(j), u_(j), v_(j): LL Public Key

M_(j), U_(j), V_(j): LL Secret Key

j: service provider

In this case, it is assumed that the service user 100 can verify that the values included in the LL public key are values issued by the anonymous ID verification server 130 for the service provision server 120. For this operation, a certificate for the LL public key may also be used.

In the group signature creation (sign) procedure at step S220, the service user 100 creates a group signature in cooperation with the service provision server 120, as shown in FIG. 6.

At step S221, the service user 100 acquires an LL public key (LLpk_(SP)[j]) from the service provision server 120.

At step S222, the service user 100 creates a group signature using the group public key (gpk), the LL public key (LLpk_(SP)[j]), a secret key (gsk[i]=(Â_(i), x_(i), z_(i), y_(i))), and a message M.

That is, after any random numbers (α, βεZ_(p)) have been selected, “T₁=u_(j) ^(α), T₂=v_(j) ^(β), T₃=A_(i)h_(j) ^(α+β) and T₄=g₀ ^(−z) ^(i) m_(j) ^(α−β)” are calculated, and “δ₁=x_(i)α and δ₂=x_(i)β” are then calculated. Furthermore, any random numbers (r_(α), r_(β), r_(x) _(i) , r_(y) _(i) , r_(z) _(i) , r_(δ) ₁ , r_(δ) ₂ εZ_(p)) are selected, and “R₁, R₂, R₃, R₄, R₅, R₆” are calculated by the following procedure. After the hash value (c=H(M, T₁, T₂, T₃, T₄, R₁, R₂, R₃, R₄, R₅, R₆)) has been calculated using the calculated values and the message M, “s_(α)=r_(α)+cα, s_(β)=r_(β)+cβ, s_(x) _(i) =r_(x) _(i) +cx_(i), s_(z) _(i) =r_(z) _(i) +cz_(i), s_(y) _(i) =r_(y) _(i) +cy_(i), s_(δ) ₁ =r_(δ) ₁ +cδ₁ and s_(δ) ₂ =r_(δ) ₂ +cδ₂” are calculated, so that a group signature (σ=(T₁, T₂, T₃, T₄, c, s_(α), s_(β), s_(x) _(i) , s_(y) _(i) , s_(z) _(i) s_(δ) ₁ , s_(δ) ₂ )) is created.

$\begin{matrix} {\mspace{76mu} {{\left. R_{1}\leftarrow u_{j}^{r_{\alpha}} \right.,\left. R_{2}\leftarrow v_{j}^{r_{\beta}} \right.}{\left. R_{3}\leftarrow{{e\left( {T_{3},g_{2}} \right)}^{r_{x_{i}}} \cdot {e\left( {h_{j},w} \right)}^{{- r_{\alpha}} - r_{\beta}} \cdot {e\left( {h_{j},g_{2}} \right)}^{{- r_{\delta_{1}}} - r_{\delta_{2}}} \cdot {e\left( {g_{3},g_{2}} \right)}^{r_{y_{i}}} \cdot {e\left( {g_{4},g_{2}} \right)}^{r_{z_{i}}}} \right.,\mspace{20mu} \left. R_{4}\leftarrow{g_{0}^{r_{z_{i}}} \cdot m_{j}^{{- r_{\alpha}} + r_{\beta}}} \right.,\left. R_{5}\leftarrow{T_{1}^{r_{x_{i}}}u_{j}^{- r_{\delta_{1}}}} \right.,\left. R_{6}\leftarrow{T_{2}^{r_{x_{i}}}v_{j}^{- r_{\delta_{2}}}} \right.}}} & (3) \end{matrix}$

j: service provider g₀, g₁, g₂, g₃, g₄, w: group public key R₁, R₂, R₃, R₄, R₅, R₆, r_(α), r_(β), r_(x) _(i) , r_(y) _(i) , r_(z) _(i) , r_(δ) ₁ , r_(δ) ₂ εZ_(p): temporary variable

At step S223, the service user 100 transfers the group signature created at step S222 to the service provision server 120.

In the group signature verification procedure at step S230, the service provision server 120 or any participant performs the following procedure with respect to the group public key (gpk), the LL public key (LLpk_(SP)[j]), the message M, and the group signature ({tilde over (σ)}=({tilde over (T)}₁, {tilde over (T)}₂, {tilde over (T)}₃, {tilde over (T)}₄, {tilde over (c)}, {tilde over (s)}_(α), {tilde over (s)}_(β),{tilde over (s)}_(x) _(i) , {tilde over (s)}_(y) _(i) , {tilde over (s)}_(z) _(i) {tilde over (s)}_(δ) ₁ , {tilde over (s)}_(δ) ₂ )).

The service provision server 120 or any participant calculates {tilde over (R)}₁, {tilde over (R)}₂, {tilde over (R)}₃, {tilde over (R)}₄, {tilde over (R)}₅, {tilde over (R)}₆ using the following Equation 4, and generates the hash value (c=H(M, T₁, T₂, T₃, T₄, R₁, R₂, R₃, R₄, R₅, R₆)) using the calculated values {tilde over (R)}₁, {tilde over (R)}₂, {tilde over (R)}₃, {tilde over (R)}₄, {tilde over (R)}₅, {tilde over (R)}₆, the values {tilde over (T)}₁, {tilde over (T)}₂, {tilde over (T)}₃, {tilde over (T)}₄ included in the group signature, and the message M, and determines whether the hash value is identical to {tilde over (c)} contained in the group signature. If it is determined that the two values are identical, ‘1’ (indicative of a valid group signature) is output, otherwise ‘0’ (indicative of an invalid group signature) is output.

$\mspace{79mu} {{{{\overset{\sim}{R}}_{1}u_{j}^{{\overset{\sim}{s}}_{\alpha}}} \cdot {\overset{\sim}{T}}_{1}^{- \overset{\sim}{c}}},{{{\overset{\sim}{R}}_{2}v_{j}^{{\overset{\sim}{s}}_{\beta}}} \cdot {\overset{\sim}{T}}_{2}^{- \overset{\sim}{c}}}}$ ${{\overset{\sim}{R}}_{3}{e\left( {{\overset{\sim}{T}}_{3},g_{2}} \right)}^{{\overset{\sim}{s}}_{x}}} \cdot {e\left( {h_{j},w} \right)}^{{- {\overset{\sim}{s}}_{\alpha}} - {\overset{\sim}{s}}_{\beta}} \cdot {e\left( {h_{j},g_{2}} \right)}^{{- {\overset{\sim}{s}}_{\delta \; 1}} - {\overset{\sim}{s}}_{\delta_{2}}} \cdot {e\left( {g_{3},g_{2}} \right)}^{\overset{\sim}{s}\gamma_{i}} \cdot {e\left( {g_{4},g_{2}} \right)}^{{\overset{.}{s}}_{s_{i}}} \cdot \left( \frac{e\left( {{\overset{\sim}{T}}_{3},w} \right)}{e\left( {g_{1},g_{2}} \right)} \right)^{\overset{\sim}{c}}$ $\mspace{79mu} {{{{{\overset{\sim}{R}}_{4}{\overset{\sim}{T}}_{4}^{\overset{\sim}{c}}} \cdot m_{j}^{{- {\overset{\sim}{s}}_{a}} + {\overset{\sim}{s}}_{\beta}}}g_{0}^{{\overset{\sim}{s}}_{x_{i}}}},\mspace{79mu} {{{\overset{\sim}{R}}_{5}{\overset{\sim}{T}}_{1}^{{\overset{\sim}{s}}_{x}}} \cdot u_{j}^{- {\overset{\sim}{s}}_{\delta_{1}}}},{{{\overset{\sim}{R}}_{6}{\overset{\sim}{T}}_{2}^{{\overset{\sim}{s}}_{x}}} \cdot v_{j}^{- {\overset{\sim}{s}}_{\delta_{2}}}}}$

(4) e( ): cryptographic bilinear pairing map

In the signer identification (open) procedure at step S240, the anonymous ID verification server 130 and the anonymous authentication server 110 perform the following procedure.

The anonymous ID verification server 130 performs the following operation with respect to parameters provided by the service provision server 120 or any participant, that is, the group public key (gpk), the LL public key (LLpk_(SP)[j]), the trace key(tk_(SP)[j]=(ξ_(1j), ξ_(2j), χ_(j))) corresponding to the LL public key, the message M, and the group signature ({tilde over (σ)}=({tilde over (T)}₁, {tilde over (T)}₂, {tilde over (T)}₃, {tilde over (T)}₄, {tilde over (c)}, {tilde over (s)}_(α), {tilde over (s)}_(β),{tilde over (s)}_(x) _(i) , {tilde over (s)}_(y) _(i) , {tilde over (s)}_(z) _(i) {tilde over (s)}_(δ) ₁ , {tilde over (s)}_(δ) ₂ )) corresponding to the message M.

First, after the propriety of the group signature has been verified, an anonymous ID (B_(i)=g₀ ^(−z) ^(i) ={tilde over (T)}₄·({tilde over (T)}₁ ^(−ξ) ^(1j) {tilde over (T)}₂ ^(ξ) ^(2j) )) is calculated using tk_(SP)[j]=(ξ_(1j), ξ_(2j), χ_(j)). In this case, updated anonymous ID information (A_(i)={tilde over (T)}₃·({tilde over (T)}₁ ^(−χ) ^(j) ^(ξ) ^(1j) {tilde over (T)}₂ ^(−χ) ^(j) ^(ξ) ^(2j) )) can also be decoded using three types of parameters contained in the group signature, that is, {tilde over (T)}₁←u_(j) ^(α), {tilde over (T)}₂←v_(j) ^(β), and {tilde over (T)}₃←A_(i)h_(i) ^(α+β) and the trace key(tk_(SP)[j]=(ξ_(1j), ξ_(2j), χ_(j))).

Further, the anonymous authentication server 110 and the anonymous ID verification server 130 identify a user corresponding to the anonymous ID in cooperation with each other (if necessary, a service user having identification information, and the group member key corresponding to the anonymous ID is searched for in the user list (User-List) of the anonymous authentication server 110 by making a comparison).

In the local link procedure at step S250, the service provision server 120 operates as shown in FIG. 8, and then ensures linkability within the same service domain.

At step S251, the service provision server 120 acquires the group public key, the LL public key, its own LL secret key (LLsk_(SP)[j]=(M_(j), U_(j), V_(j))), the message M, and the group signature ({tilde over (σ)}=({tilde over (T)}₁, {tilde over (T)}₂, {tilde over (T)}₃, {tilde over (T)}₄, {tilde over (c)}, {tilde over (s)}_(α), {tilde over (s)}_(β),{tilde over (s)}_(x) _(i) , {tilde over (s)}_(y) _(i) , {tilde over (s)}_(z) _(i) {tilde over (s)}_(δ) ₁ , {tilde over (s)}_(δ) ₂ )) corresponding to the message, and thereafter determines based on a group signature verification algorithm whether the group signature is proper for its own LL public key. If it is determined that the group signature is proper, the service provision server 120 calculates the virtual index of the service user 100 using its own LL secret key using the following Equation 5:

P _(ij) ←e({tilde over (T)} ₄ ,M _(j))·e({tilde over (T)} ₁ ,U _(j))⁻¹ ·e({tilde over (T)} ₂ ,V _(j))  (5)

e( ) cryptographic bilinear pairing map

M_(j), U_(j), V_(j): LL Secret Key

At step S252, the service provision server 120 acquires P←e({tilde over (T)}₄, M_(j))·e({tilde over (T)}₁, U_(j))⁻¹·e({tilde over (T)}₂, V_(j))=e(B_(i), M_(j))=e(g₀ ^(−z) ^(i) , M_(j)) as a virtual index, registers the virtual index in an anonymous token list (AT-List), and then ensures local linkability.

As described above, according to the local link procedure S250 of the present invention, the service provision server 120 cannot calculate A_(i) (or x_(i), z_(i) or B_(i)=g₀ ^(−z) ^(i) ) corresponding to the anonymous ID of the anonymous user, but can calculate the virtual index (P_(ij)=e(B_(i), M_(j))=e(g₀ ^(−z) ^(i) , M_(j))) having the fixed value.

Then, the service provision server 120 can classify service users using virtual indices that have fixed values for respective service users, and can perform functions such as a mileage service, the assignment of black marks, and the analysis of service usage records using the virtual indices.

That is, the service provision server 120 can support linkability within the same service domain while maintaining anonymity.

However, although service providers j and k cooperate with each other, they cannot calculate the same virtual index from the group signatures of the same user, thus making it impossible to determine whether corresponding users are the same user.

That is, since the service providers j and k can calculate only P_(ij)=e(B_(i), M_(j))=e(g₀ ^(−z) ^(i) , M_(j)) and P_(ik)=e(B_(i), M_(k))=e(g₀ ^(−z) ^(i) , M_(k)) from the individual group signatures received from the same user, they cannot acquire the virtual index having the same value. Further, the service provider k cannot calculate a unique virtual index from the group signatures of the same service user which the service provider j received (or vice versa).

Therefore, since the anonymous authentication service method can ensure linkability only in the same service domain and cannot support linking between different service domains, a local linkability function can be satisfied.

Next, a method of verifying key validity in an anonymous authentication service for providing local linkability will be described in detail with reference to FIG. 8.

FIG. 8 is a flowchart showing a method of verifying key validity according to an embodiment of the present invention.

The present invention adds H_(j)(where H_(j)=M_(j) ^(χ) ^(j) ⁻¹ ) to the LL secret key (LLsk_(SP)[j]=(M_(j), U_(j), V_(j))), which is provided by the anonymous ID verification server 130 to the service provision server 120 at the service provider join step S212. Therefore, in the key validity verification method according to the embodiment of the present invention, the LL secret key is implemented as “LLsk_(SP)[j]=(M_(j), U_(j), U_(j), V_(j))”.

When the LL secret key is implemented in this way, the service provision server 120 can generate two unique indices for linking in the group signature verification procedure at step S230. In the prior art, only the virtual index P_(ij)=e(B_(i), M_(j))=e(g₀ ^(−z) ^(i) , M_(j)) can be generated, but, in the present invention, P2_(ij)=e(T₃, H_(j))·e(T₁, U_(j))⁻¹·e(T₂, V_(j))⁻¹=e(A_(i), H_(j)) can be generated as a new virtual index. In this case, when the key of a relevant user in a given group is revoked, a virtual index for the relevant user whose key has been revoked is generated and is then used for comparison.

As shown in FIG. 8, the key validity verification method is performed by the anonymous authentication server 110 and the service provision server 120.

At step S810, the anonymous authentication server 110 revokes an anonymous secret key currently in its possession for a specific reason. Here, the specific reason may include the user's request for the revocation of a key, the expiration of the validity term, the exposure of the key, etc.

A set of keys of the users that are revoked due to the revocation of the anonymous secret key is given as {gsk′[k]=(A′_(k), x′_(k), z′_(k), y′_(k)|k=1, . . . r}.

At step S820, the anonymous authentication server 110 generates a Revocation List (RL) and publishes the revocation list. Here, the revocation list is represented by the following Equation 6:

RL={(A′ _(k))|k=1 . . . r}  (6)

At step S830, the service provision server 120 generates a Local Revocation List (LRL) using the RL and its own LL secret key. Here, the LRL is represented by the following Equation 7:

LRL[j]={e(A′ _(k) ,H _(j))|k=1 . . . r}  (7)

e( ): cryptographic bilinear pairing map

The local revocation list does not influence the procedure for requesting and verifying a group signature in the anonymous authentication service method because the service provision server 120 can periodically access the anonymous authentication server 110 and perform calculations in advance.

At step S840, the service provision server 120 calculates the virtual index of the service user 100 when the service user 100 creates a signature. Here, the virtual index according to an embodiment of the present invention is represented by the following Equation 8:

P2_(ij) =e(A _(i) ,H _(j))  (8)

e( ): cryptographic bilinear pairing map

At step S850, the service provision server 120 verifies whether the key of the service user 100 is valid, on the basis of whether the virtual index is included in the local revocation list.

In the prior art, the computation time required in the key update scheme or the VLR scheme was needed to verify key validity. In contrast, the present invention additionally calculates a virtual index at the time of verifying a signature, and compares the virtual index with the local revocation list, thus efficiently inspecting key validity.

FIG. 9 is a block diagram showing a server for performing the key validity verification method according to an embodiment of the present invention.

As shown in FIG. 9, a service provision server 120 includes a reception module 121, a list generation module 122, an index generation module 123, and a verification module 124.

The reception module 121 receives a revocation list from an anonymous authentication server 110.

The list generation module 122 generates a local revocation list (LRL) using the revocation list and its own LL secret key. Here, the local revocation list is represented by the above Equation 7.

When a service user 100 creates a signature, the index generation module 123 calculates the virtual index of the service user 100, as given by the above Equation 8.

The verification module 124 verifies whether the key of the service user 100 is valid, on the basis of whether the virtual index is included in the local revocation list.

Next, an example of the verification of key validity will be described in detail with reference to FIG. 10.

FIG. 10 is a diagram illustrating an example of the verification of key validity according to an embodiment of the present invention.

As shown in FIG. 10, after a key “usk[1]=(A₁, x₁, y₁, z₁)” is revoked from group 1, a service user 1 100_(—)1 creates a new key “usk[1]′=(A′₁, x′₁, y′₁, z₁)” in group 3.

After a key “usk[2]=(A₂, x₂, y₂, z₂)” is revoked from group 1, a service user 2 100_(—)2 additionally undergoes a procedure for generating a key in group 4 and revoking the key from group 4 twice (that is, usk[2]′=(A′₂, x′₂, y′₂, z₂) and usk[2]″=(A″₂, x″₂, y″₂, z₂)).

After a key (usk[3]=(A₃, x₃, y₃, z₃)) is revoked from the group 1, a service user 3 100_(—)3 generates a new key (usk[3]′=(A′₃, x′₃, y′₃, z₃)) in group 4.

That is, a revocation list for the group 1 is “RL₁=(A₁, A₂, A₃)”, and the revocation list for the group 4 is “RL₄=(A′₂, A″₂)”.

The service provision server 120 generates its own local revocation list using the revocation list for group 4. Such a local revocation list is changed, as given by the following Equation 9:

LRL₄ ={e(A′ ₂ ,H _(j))}→{e(A′ ₂ ,H _(j)),e(A″ ₂ ,H _(j))}  (9)

e( ): cryptographic bilinear pairing map

In this situation, it is assumed that the service user 3 100_(—)3 generates a group signature and requests the service provision server 120 to authenticate the group signature.

In this case, the service user 3 100_(—)3 generates a signature using its own secret key (usk[3]′=(A′₃, x′₃, y′₃, z₃)), a group public key (gpk₄=(g₀, g″₁, g″₂, g″₃, g″₄, w″)), and the LL public key (LLpk_(SP)=(u_(j)=m_(j) ^(ξ) ¹ ⁻¹ , v_(j)=m_(j) ^(ξ) ² ⁻¹ , h_(j), m_(j))) of the service provision server 120.

The service provision server 120 generates a virtual index 2 based on the signature, wherein the virtual index 2 is represented by the following Equation 10:

P2_(3j) =e(A ₃ ,H _(j))←e(T ₃ ,H _(j))·e(T ₁ ,U _(j))⁻¹ e(T ₂ ,V _(j))⁻¹  (10)

e( ) cryptographic bilinear pairing map

The service provision server 120 can verify whether the key of the service user 3 100_(—)3 has been revoked by determining whether the virtual index 2 is included in the local revocation list LRL₄ given in Equation 9. In this case, since the virtual index 2 is not present in the local revocation list, it can be proved that authentication has been requested using a valid key that has not been revoked.

For example, when the service user 2 100_(—)2 requests authentication from the service provision server 120 using its own secret key (usk[2]″=(A″₂, x″₂, y″₂, z₂)), the service provision server 120 calculates the virtual index 2 (P2_(2j)=e(A″₂, H_(j))).

The service provision server 120 can be aware of the fact that the virtual index 2 is included in the local revocation list LRL₄, and can immediately appreciate that authentication has been requested using the revoked key.

After verifying whether the key used to request authentication has been revoked, the service provision server 120 can recalculate the virtual index (P_(ij)=e(B_(i), M_(j))=e(g₀ ^(−z) ^(i) , M_(j))), as in the case of the anonymous service method that provides local linkability, thus managing members.

The reason for managing members using the conventional virtual indices in this way is that although a procedure, such as update after the revocation of a key, is performed on a service user in a specific service domain, the conventional virtual index (P_(ij)=e(B_(i), M_(j))=e(g₀ ^(−z) ^(i) , M_(j))) continuously outputs a unique value regardless of such a procedure.

In contrast, since the value of the virtual index (P2_(ij)=e(A_(i), H_(j))) required to verify key validity in the key validity verification method according to the embodiment of the present invention continuously changes, only information about a change in the key and about whether the key has been revoked can be verified. Generally, anonymous authentication schemes for providing local linkability can generate a virtual index, and efficiency verify key validity in such a way as to generate a local revocation list using a revocation list and to compare the virtual index with the local revocation list. Furthermore, the scheme for generating a revocation list and a local revocation list can be very easily implemented by applying the present invention.

According to embodiments of the present invention, the key validity verification method is advantageous in that the computation time required to verify key validity can be reduced when service users or service providers individually create signatures or verify the signatures while providing various types of services based on anonymous authentication.

As described above, optimal embodiments of the present invention have been disclosed in the drawings and the present specification. In this case, although specific terms have been used, those terms are merely intended to describe the present invention and are not intended to limit the meanings and the scope of the present invention as disclosed in the accompanying claims.

Therefore, those skilled in the art will appreciate that various modifications and other equivalent embodiments are also possible given the above description. Therefore, the technical scope of the present invention should be defined by the technical spirit of the accompanying claims. 

1. A method of verifying key validity, the method being configured such that a service provision server verifies key validity in an anonymous service for providing local linkability, comprising: receiving a revocation list at the service provision server; generating a local revocation list by using the received revocation list and a secret key; calculating a virtual index of a service user required to verify validity of a key of the service user; and verifying whether a key of the service user is valid, based on whether the virtual index is included in the local revocation list.
 2. The method of claim 1, wherein the receiving the revocation list is configured such that the service provision server receives the revocation list that corresponds to a set of keys of users, generated when an anonymous authentication server revokes anonymous secret keys, and that has been published by the anonymous authentication server.
 3. The method of claim 1, wherein the verifying whether the key of the service user is valid comprises determining that authentication has been requested using a valid key that has not been revoked if the virtual index is not included in the local revocation list.
 4. The method of claim 1, wherein the verifying whether the key of the service user is valid comprises determining that authentication has been requested using an invalid key that has been revoked if the virtual index is included in the local revocation list.
 5. A service provision server for verifying key validity in an anonymous service for providing local linkability, comprising a list generation module for generating a local revocation list by using a revocation list and a secret key; an index generation module for generating a virtual index of a service user; and a verification module for verifying whether a key of the service user is valid, based on whether the virtual index is included in the local revocation list.
 6. The service provision server of claim 5, wherein the revocation list is a list that corresponds to a set of keys of users, generated when an anonymous authentication server revokes anonymous secret keys, and that has been published by the anonymous authentication server.
 7. The service provision server of claim 5, wherein the verification module is configured either to determine that authentication has been requested using a valid key that has not been revoked if the virtual index is not included in the local revocation list or to determine that authentication has been requested using an invalid key that has been revoked if the virtual index is included in the local revocation list. 